JSONSpec: AST as a Service

原文发表于 2015-07-27，我的lofter：http://kimleo.lofter.com/post/46977_7c0165f

今晚刚刚设置好自己的Medium账户，然后就看到了这篇文章（原链接已失效），遂想起来之前关于Workflow的想法，以及一直在纠结究竟要不要提出的概念：AST as a Service。

当然，Adolfo Rodriguez关于Relevant的这篇文章，仍然更像是把JSON作为描述Workflow的语言（参见其GitHub Repo），而且依据我们之前的论述，一个语言只要满足Repeating、Branching和Reference就能够完成大多数任务了。

然而问题究竟在哪儿呢？

首先是关于是否有必要在请求的结果中描述逻辑的问题。

比如：

"foo":true, 

"cities":["Montreal","Toronto"], 

"city": {
    "_IF":"{foo}",
    "_THEN":{
        "city":{"_PATH":["cities",0]},
        "_RETURN":"{city}"
    },
    "_ELSE":{"_PATH":["cities",1]}
}

大致相当于下面的JS代码：

var foo=true, cities = ["Montreal", "Toronto"], city;

if(foo) {
    city = cities[0];
} else {
    city = cities[1];
}

但是，当这段代码逻辑出现的时候，其实就可以直接对其进行求值然后变成：

{
    "city": "Montreal"
}

简直节省了大量的带宽和客户端的业务量。

当然，也有一个理由让客户端知道如何处理这样的业务逻辑。比如，要求Dynamic或者是Reactive时，客户端就可以直接对当前获得到的业务逻辑，自己就能进行处理了。

那么问题来了，究竟什么时候去更新这套业务逻辑，或者是数据呢？

所以，这仍然是一个问题。

其次，是语言设计的粒度。

抛开可用性不谈，我觉得实际上并不需要精确地描述出每一个Math甚至是Date以及相关的东西。其实只要能够表述出不同的state、view和transition就足够了。因为这才是“Business Process”，而具体的数据交互和展现交给state和view来搞定就好。

另外，关于AST as a Service，是一个不错的发展趋势。只要开发者利用自己熟悉的工具生成具有统一规范的JSON数据（AST），就可以作为一个后台服务或者一项特殊的任务（task）——比如批量处理大规模的数据——来运行。（嗯，听起来还是像BaaS的做法），于是，在部署的时候更多的只要考虑这个AST的Interpreter如何实际规划就好。

当然，这个Common AST也并不一定真的就是一个树状结构，比如JavaScript。

=============================

结论：Workflow大法好！